Method and Apparatus for Detecting and Handling Peer Faults in Peer-to-Peer Network

ABSTRACT

A method and apparatus for detecting and handling peer faults in a Peer-to-Peer network are disclosed. A peer in the P2P network receives a diagnosis request message; then detects whether a peer is faulty according to a preset fault detection method; and sends a diagnosis response message to a source peer that constructs the diagnosis request message or a peer specified by the diagnosis request message, where the diagnosis response message carries a detection result, and the detection result carries information about the faulty peer if the peer is detected as faulty. Through the technical solution under the present invention, the faults of the peers on the forwarding path in the P2P network can be detected.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of International Application No.PCT/CN2008/072760, filed on Oct. 21, 2008, which claims priority toChinese Patent Application No. 200710165511.9, filed on Oct. 26, 2007,both of which are hereby incorporated by reference in their entireties.

FIELD OF THE INVENTION

The present invention relates to network and communication technologies,and in particular, to a method and apparatus for detecting and handlingpeer faults in a Peer-to-Peer (P2P) network.

BACKGROUND OF THE INVENTION

A P2P network is made up of multiple interconnected nodes which areknown as peers. In a P2P network, each peer contributes itscapabilities, and all the peers work together to provide P2P networkservices. Currently, the P2P network services include distributedstorage services and distributed transmission services. Unlike the nodesin a traditional client/server architecture, all nodes in a P2P networkare peers, and the peers that make up the P2P network provide servicesin distributed mode. The peers that make up the P2P network have aunique identifier called “peer-ID” in the P2P network. The resourcesstored in the P2P network through the distributed storage services havetheir independent identifier called “resource-ID” in the P2P network.The P2P network uses the identifiers (namely, peer-IDs and resource-IDs)for routing. When deciding the route of forwarding, a peer in the P2Pnetwork selects a peer in its P2P network routing table, and uses theselected peer as the next hop of the P2P network route, where theselected peer has a peer-ID which is closer to the destination ID.Currently, three P2P network routing modes (also known as forwardingmodes) are available: iterative mode, recursive mode, and semi-recursivemode. The iterative mode differs from the recursive mode and thesemi-recursive mode in that: In iterative mode, the intermediate peerdoes not forward packets, but notifies the found next hop to the sourcepeer, and then the source peer communicates with the next hop. Thisprocess is repeated until the packets arrive at the destination peer. Inrecursive or semi-recursive mode, however, each intermediate peerforwards the packets to the found next hop directly, and repeatsforwarding until the packets arrive at the destination peer. Inrecursive mode, the reply message is returned by the destination peeralong the forwarding path to an upstream peer until the source peer, andthe reply message is forwarded through intermediate peers. Insemi-recursive mode, the reply message is sent by the destination peerto the source peer directly, without being forwarded by the intermediatepeers.

The P2P network is characterized by self organization and selfmanagement. The peers in the P2P network can join and leave the P2Pnetwork freely, which makes the P2P network highly extensible.Meanwhile, in the P2P network, multiple peers work together to provideservices, thus avoiding single-point failure in the traditionalclient/server architecture. Although the fault of a peer does not affectall peers in the P2P network, the fault makes some peers unable toobtain P2P network services, namely, leads to deterioration of theQuality of Service (QoS) of the P2P network or even service interruptionwithin a period. The distributed feature of the P2P network makes ithard to detect or handle the faults (such as peer failure, peercongestion, and forwarding error) on the forwarding path. Although themaintenance and management system of the existing P2P network can detectand locate the join and leave of the peers, no corresponding mechanismis available for detecting and handling the faults of the peers, whichaffects the P2P network services.

SUMMARY OF THE INVENTION

Embodiments of the present invention provide a method and apparatus fordetecting and handling faults of peers on a forwarding path in a P2Pnetwork to improve the reliability and efficiency of data transmissionin the P2P network.

A method for detecting peer faults in an embodiment of the presentinvention includes:

receiving a diagnosis request message;

detecting whether a peer is faulty according to a preset fault detectionrule;

sending a diagnosis response message to a source peer that constructsthe diagnosis request message or a peer specified by the diagnosisrequest message, wherein: the diagnosis response message carries adetection result, and the detection result carries information about thefaulty peer if the peer is detected as faulty.

A method for handling peer faults in an embodiment of the presentinvention includes:

receiving a diagnosis response message;

determining a faulty peer according to the diagnosis response message;

constructing a packet to be sent; adding information about the faultypeer to the packet, and instructing intermediate peers to bypass thefaulty peer in the process of forwarding the packet; and

sending the packet. An apparatus for detecting peer faults in anembodiment of the present invention includes:

a message receiving unit, adapted to receive a diagnosis requestmessage;

a fault detecting unit, adapted to check whether a peer is faultyaccording to a preset fault detection rule;

a sending unit, adapted to send a diagnosis response message to a sourcepeer that constructs the diagnosis request message or a peer specifiedby the diagnosis request message, where: the diagnosis response messagecarries a detection result, and the detection result carries informationabout the faulty peer if the peer is detected as faulty.

An apparatus for handling peer faults in an embodiment of the presentinvention includes:

a receiving unit, adapted to receive a diagnosis response message;

a peer identifying unit, adapted to determine a faulty peer according tothe diagnosis response message;

a packet constructing unit, adapted to: construct a packet to be sent,add information about the faulty peer to the packet, and instructintermediate peers to bypass the faulty peer in the process offorwarding the packet; and

a packet sending unit, adapted to send the packet.

As seen from the technical solution under the present invention, adiagnosis request message triggers the peer to detect the fault state ofthis peer, thus providing a path fault detection mechanism for the P2Pnetwork; after detecting a fault, the peer sends the detection result tothe corresponding peer such as the source peer so that the source peerknows whether the forwarding path is smooth and decides whether to sendthe packet; further, the returned detection result carries informationabout the faulty peer, and therefore, the source peer can locate thefaulty peer and bypass it when sending the packet, thus improving thereliability and efficiency of data transmission in the P2P network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart of a method for detecting peer faults in a firstembodiment of the present invention;

FIG. 2 is a flowchart of a method for detecting peer faults in a secondembodiment of the present invention;

FIG. 3 is a flowchart of a method for detecting peer faults in a thirdembodiment of the present invention;

FIG. 4 is a flowchart of a method for detecting peer faults in a fourthembodiment of the present invention;

FIG. 5 is a flowchart of a method for handling peer faults in anembodiment of the present invention;

FIG. 6 is a flowchart of a method for detecting peer faults in a fifthembodiment of the present invention;

FIG. 7 shows a structure of an apparatus for detecting peer faults inthe first embodiment of the present invention;

FIG. 8 shows a structure of an apparatus for detecting peer faults inthe second embodiment of the present invention;

FIG. 9 shows a structure of an apparatus for detecting peer faults inthe third embodiment of the present invention;

FIG. 10 shows a structure of an apparatus for detecting peer faults inthe fourth embodiment of the present invention; and

FIG. 11 shows a structure of an apparatus for handling peer faults in anembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

To make the technical solution, objectives and merits of the presentinvention clearer, the following describes the embodiments of thepresent invention in detail with reference to accompanying drawings.

A method for detecting peer faults is provided in the first embodimentof the present invention. As shown in FIG. 1, the method includes:

Step 101: Receive a diagnosis request message.

The diagnosis request message may directly come from the source peerthat needs to detect the peer fault, or come from an upstream peer onthe forwarding path.

Step 102: Detect whether the peer is faulty according to the presetfault detection rule, namely, detect whether the peer can provide P2Pnetwork services normally.

Specifically, the detection may be performed by checking the resourceutilization of the processor or the network bandwidth utilization ofthis peer, and the check items include the peer congestion or busyprocessing state. The congested or busy state is determined if the checkitems reach or exceed the preset threshold. The threshold may be setaccording to the use environment or the processing efficiency of thispeer.

The upstream peer may be checked for faults, such as diagnosis requestforwarding errors. Specifically, the upstream peer ID may be comparedwith the destination ID of the diagnosis request message. If theupstream peer ID is closer to the destination ID of the diagnosisrequest message, it is deemed that the upstream node forwards thediagnosis request message incorrectly. A downstream peer may be checkedfor faults. If the downstream peer is unreachable, a standard protocolmessage may be used to determine the fault of the downstream peer. Forexample, a message that requires response may be sent to the downstreampeer. If no response is received, it is determined that the downstreampeer is faulty.

Step 103: Send a diagnosis response message to a source peer thatconstructs the diagnosis request message or a peer specified by thediagnosis request message, where: the diagnosis response message carriesa detection result, and the detection result carries information aboutthe faulty peer if the peer is detected as faulty.

Generally, the diagnosis response message is sent in preset sendingmode. However, if the diagnosis request message specifies a sendingmode, the diagnosis response message needs to be sent in specifiedsending mode.

Generally, the diagnosis response message is sent to the source peerthat constructs the diagnosis request message. However, if the diagnosisrequest message specifies a peer that receives the diagnosis responsemessage, the diagnosis response message needs to be sent to thespecified peer.

The information about the faulty peer in the detection result may letthe peer that receives the diagnosis response message locate the faultypeer.

Preferably, the diagnosis response message may carry information aboutthe fault type. The peer that receives the diagnosis response messagemay be a source peer that constructs the diagnosis request message, or apeer specified by the diagnosis request message.

In conclusion, in the embodiments of the present invention, a diagnosisrequest message triggers the peer to detect the fault state of thispeer, thus providing a fault detection mechanism for the P2P network;after detecting a fault, the peer sends the detection result to thecorresponding peer such as the source peer so that the source peer knowswhether the forwarding path is smooth and decides whether to send thepacket; further, the returned detection result carries information aboutthe faulty peer, and therefore, the source peer can locate the faultypeer and bypass it when sending the packet, thus improving thereliability and efficiency of data transmission in the P2P network.

At the time of receiving the diagnosis request message, the time ofreceiving the diagnosis request message is recorded, and the time ofreceiving the diagnosis request message is sent to the source peer thatconstructs the diagnosis request message or the peer specified by thediagnosis request message; all the peers on the forwarding path send thetime of receiving the diagnosis request message to the source peer thatconstructs the diagnosis request message or the peer specified by thediagnosis request message, and therefore, the source peer thatconstructs the diagnosis request message or the peer specified by thediagnosis request message knows the time spent in transmitting thediagnosis request message between the two peers, determines the delay oftransmitting the diagnosis request message between the two peersaccording to the preset rule, and judges whether the forwarding path isfaulty (for example, congested). The time of receiving the diagnosisrequest message may be carried in the diagnosis response message, orcarried in other messages, or sent separately. The embodiments of thepresent invention do not limit how to send the time of receiving thediagnosis request message.

In practice, before checking whether the peer is faulty according to thepreset fault detection method, the method further includes the followingstep:

judging whether the diagnosis request message is valid; and, if thediagnosis request message is valid, check whether the peer is faultyaccording to the preset fault detection method. The validity of thediagnosis request message may be judged according to the protocol thatgoverns the diagnosis request message. For example, if the appliedprotocol is P2P SIP Peer, it is only necessary to judge whether thediagnosis request message complies with the P2P SIP Peer protocol;moreover, the validity of the diagnosis request message may be judgedaccording to the pre-appointed security mechanism, for example, throughcheck codes.

Moreover, if the diagnosis request message carries the validity periodof the diagnosis request message in the network, for example, carriesTime To Live (TTL) measured by hop count or TTL measured by time, ajudgment may be made about whether the validity period of the diagnosisrequest message in the network expires. If the validity period has notexpired, the diagnosis request message is valid. After the diagnosisrequest message is determined as valid, the process goes on. If thediagnosis request message is determined as invalid, the diagnosisrequest message may be discarded, and the information about expiry ofthe diagnosis request message may be sent to the corresponding peer suchas the source peer, or no operation is performed. The embodiments of thepresent invention do not limit the operations to be performed after thediagnosis request message is determined as invalid.

FIG. 2 is a flowchart of a method for detecting peer faults in thesecond embodiment of the present invention. The method includes thefollowing steps:

Step 201: Receive the diagnosis request message, and record the time ofreceiving the diagnosis request message.

Step 202: Judge whether the diagnosis request message is valid. If thediagnosis request message is valid, proceed to step 203; otherwise, endthe process.

Step 203: Detect whether the peer is faulty according to a preset faultdetection rule.

Step 204: Judge whether the destination peer carried in the diagnosisrequest message is a current peer; if such is the case, skip to step206; otherwise, proceed to step 205.

If the current peer is the destination peer, it is not necessary toforward the diagnosis request message, and a diagnosis response messageis sent directly after the fault state of the current peer is detected,thus completing the diagnosis for the whole forwarding path.

Step 205: Forward the diagnosis request message to the downstream peercloser to the destination peer or to the destination peer.

Before the diagnosis request message is forwarded, the routing table maybe searched for the downstream peer closer to the destination peer,namely, the next hop, and the diagnosis request message is forwarded tothe found downstream peer; if the downstream peer is the destinationpeer, the diagnosis request message is sent to the destination peerdirectly.

Step 206: Send a diagnosis response message to a source peer thatconstructs the diagnosis request message or a peer specified by thediagnosis request message, where the diagnosis response message carriesa detection result, time of receiving the diagnosis request message, andinformation about the receiving peer that forwards the diagnosis requestmessage.

In the process of forwarding the diagnosis request message to thedownstream peer closer to the destination peer, the information aboutthe receiving peer that forwards the diagnosis request message is theinformation about the downstream peer closer to the destination peer; inthe process of forwarding the diagnosis request message to thedestination peer, the information about the receiving peer that forwardsthe diagnosis request message is the information about the destinationpeer.

In this embodiment, the detection result, the time of receiving thediagnosis request message, and the information about the receiving peerthat forwards the diagnosis request message are carried in the diagnosisresponse message. In fact, the detection result, the time of receivingthe diagnosis request message, and the information about the receivingpeer that forwards the diagnosis request message may be sent separately.

In this embodiment, if the current peer is not the destination peer, thediagnosis request message is forwarded to the downstream peer or thedestination peer so that the diagnosis request message may approach thedestination peer. Finally, all peers on the whole forwarding path aredetected, and the corresponding peer such as the source peer knows thestate of the whole forwarding path, which provides a basis for the pathselection in the subsequent packet forwarding.

In practice, after the downstream peer or destination peer to receivethe diagnosis request message is determined, the information about thedownstream peer or destination peer may be sent to the correspondingpeer such as the source peer so that the corresponding peer knows thepeer from which the next diagnosis response message will come. Besides,if the corresponding peer sets a time limit, and no diagnosis responsemessage is received from the downstream peer or destination peer withinthe time limit, it is determined that the downstream peer or destinationpeer is faulty, and the downstream peer or destination peer can belocated according to the information about the downstream peer ordestination peer. In this way, the faulty peer may be bypassed in thesubsequent packet forwarding. The information about the downstream peeror destination peer may be carried in the diagnosis response message, orsent separately, or carried in other messages to be sent to the sourcepeer that constructs the diagnosis request message or the peer specifiedby the diagnosis request message.

It is understandable that step 204 and step 205 may occur after step206, but step 205 is definitely after step 204, and step 206 isdefinitely after step 203.

A method for detecting peer faults is provided in the third embodimentof the present invention. As shown in FIG. 3, the method includes thefollowing steps:

Step 301: Receive the diagnosis request message, and record the time ofreceiving the diagnosis request message.

Step 302: Judge whether the diagnosis request message is valid. If thediagnosis request message is valid, proceed to step 303; otherwise, endthe process.

Step 303: Detect whether the peer is faulty according to a preset faultdetection rule.

Step 304: Judge whether the destination peer carried in the diagnosisrequest message is the current peer; if such is the case, skip to step307; otherwise, proceed to step 305.

Step 305: Judge whether the upstream peer forwards the diagnosis requestmessage incorrectly; if a forwarding error has occurred, proceed to step306; otherwise, skip to step 307.

Specifically, the forwarding error of the upstream peer may be judgedbased on the distributed algorithm used in the P2P network, destinationpeer ID of the diagnosis request message, ID of the upstream peer, andthe P2P network routing table of the current peer.

Step 306: Forward the diagnosis request message to the downstream peercloser to the destination peer or to the destination peer.

Step 307: Send a diagnosis response message to a source peer thatconstructs the diagnosis request message or a peer specified by thediagnosis request message, where the diagnosis response message carriesa detection result, time of receiving the diagnosis request message, andinformation about the receiving peer that forwards the diagnosis requestmessage.

In this embodiment, a judgment is made about whether the upstream peerforwards the diagnosis request message incorrectly, and the forwardingof the diagnosis request message to the downstream peer is ended if theupstream peer forwards the diagnosis request message incorrectly.Therefore, the convergence of the whole forwarding path is ensuredbecause the forwarding by every peer on the forwarding path isconsistent, namely, approaches the destination peer. In practice, evenif the upstream peer forwards the diagnosis request message incorrectly,the diagnosis request message may still be forwarded to the downstreampeer, especially when the information about the whole forwarding path isexpected. In this case, although the diagnosis request message isfurther forwarded to the downstream peer, the information about theerror in forwarding the diagnosis request message on the upstream peerneeds to be notified to the source peer that constructs the diagnosisrequest message or the peer specified by the diagnosis request message.Therefore, the source peer that constructs the diagnosis request messageor the peer specified by the diagnosis request message knows the fault,and can locate the faulty peer, which facilitates the troubleshooting.

It is understandable that step 304, step 305, and step 306 may occurafter step 307, but step 307 is definitely after step 303 and step 306is definitely after step 305, and step 305 is definitely after step 304.

In practice, the source peer may allow the upstream peer to reattemptforwarding of the diagnosis request message to the downstream peer afterthe upstream peer forwards the diagnosis request message incorrectly. Inthis case, after the network determines that the upstream peer forwardsthe diagnosis request message to the current peer incorrectly, thenetwork needs to further judge whether the diagnosis request messagecarries a flag indicating that the forwarding of the diagnosis requestmessage needs to be stopped when the upstream peer forwards the messageincorrectly.

If the diagnosis request message carries a flag indicating that theforwarding of the diagnosis request message needs to be stopped when theupstream peer forwards the message incorrectly, the current peer stopsforwarding the diagnosis request message to the downstream peer; if thediagnosis request message carries a flag indicating that the diagnosisrequest message needs to be further forwarded when the upstream peerforwards the message incorrectly, or if the diagnosis request messagecarries no flag indicating that the forwarding of the diagnosis requestmessage needs to be stopped when the upstream peer forwards the messageincorrectly, the current peer goes on to forward the diagnosis requestmessage to the downstream peer. The carried flag can be pre-appointed,and is not limited herein.

Further, in the process of forwarding the diagnosis request message tothe downstream peer, it is possible that the downstream peer fails toreceive the message due to network problems. In this case, in order forthe source peer that constructs the diagnosis request message or thepeer specified by the diagnosis request message to better locate thefault of the peer, it is necessary to judge whether the diagnosisrequest message is forwarded successfully after the peer forwards themessage. The method for detecting the fault of the peer in the fourthembodiment of the present invention deals with this scenario. As shownin FIG. FIG. 4, the method provided in the fourth embodiment includes:

Step 401: Receive the diagnosis request message, and record the time ofreceiving the diagnosis request message.

Step 402: Judge whether the diagnosis request message is valid. If thediagnosis request message is valid, proceed to step 403; otherwise, endthe process.

Step 403: Detect whether the peer is faulty according to a preset faultdetection rule.

Step 404: Judge whether the destination peer carried in the diagnosisrequest message is the current peer; if such is the case, skip to step407; otherwise, proceed to step 405.

Step 405: Judge whether the upstream peer forwards the diagnosis requestmessage incorrectly; if a forwarding error has occurred, proceed to step406; otherwise, skip to step 407.

Step 406: Forward the diagnosis request message to the downstream peercloser to the destination peer or to the destination peer.

Step 407: Send a diagnosis response message to a source peer thatconstructs the diagnosis request message or a peer specified by thediagnosis request message, where the diagnosis response message carriesa detection result, time of receiving the diagnosis request message, andinformation about the receiving peer that forwards the diagnosis requestmessage.

Step 408: Judge whether the diagnosis request message is forwarded tothe downstream peer or destination peer successfully; if the forwardingsucceeds, end the process; if the forwarding fails, proceed to step 409.

The success or failure of forwarding the diagnosis request message tothe downstream peer or destination peer may be judged in many modes. Forexample, the diagnosis request message may require the downstream peerthat receives the diagnosis request message to return a responsemessage, and it is deemed that the message is not forwarded successfullyif no response message is received. Alternatively, the success orfailure of forwarding the message may be judged through a responsemessage of the forwarding mechanism. For example, a judgment is madeabout whether an Internet Control Message Protocol (ICMP)-based alarmmessage (such as a Destination Unreachable message, or a Time Exceededmessage) is received, and the forwarding is regarded as failed even ifan ICMP alarm message is received. Other judgment modes may also beapplied if they are appropriate.

Step 409: Send the following information to the source peer thatconstructs the diagnosis request message or the peer specified by thediagnosis request message: information about failure of forwarding thediagnosis request message to the downstream peer closer to thedestination peer, or to the destination peer.

If it is determined that the operation of forwarding the diagnosisrequest message to the downstream peer or the destination peer occursbefore the operation of sending the diagnosis response message, theinformation about failure of forwarding the diagnosis request message tothe downstream peer or the destination peer may be carried in thediagnosis response message. In this embodiment, a judgment is made aboutwhether the diagnosis request message is forwarded successfully afterthe diagnosis request message is forwarded. If it is determined that theforwarding fails, the failure information is sent to the source peerthat constructs the diagnosis request message or the peer specified bythe diagnosis request message. Therefore, the source peer thatconstructs the diagnosis request message or the peer specified by thediagnosis request message can obtain the information about the faultydownstream peer, and locate the faulty peer and handle the fault.

In practice, the source peer may already know the fault of a peer, andmay add a flag to the diagnosis request message to indicate bypassing ofthe faulty peer in the forwarding process. Therefore, after determiningthat the diagnosis request message is forwarded unsuccessfully, theintermediate peers may further judge whether the diagnosis requestmessage carries a flag indicating the requirement for bypassing thefaulty downstream peer in the process of forwarding the diagnosisrequest message.

If the diagnosis request message carries a flag indicating therequirement for bypassing the faulty downstream peer, the current peermay select another downstream peer for forwarding the diagnosis requestmessage.

Specifically, the current peer may search the routing table for a peerwhich is different from the faulty peer and closer to the destinationpeer than the current peer, and use this peer as the next downstreampeer.

Bypassing the faulty downstream peer in the forwarding process makes itmore possible for the diagnosis request message to reach the destinationpeer.

Further, in practice, after the peer receives the diagnosis requestmessage, the peer may judge whether the destination peer is reachableaccording to the existing information about the current peer. If thedestination peer is not reachable, the peer sends the information aboutnon-reachability of the destination peer directly to the source peerthat constructs the diagnosis request message or the peer specified bythe diagnosis request message, thus improving the efficiency of pathdiagnosis. Specifically, the reachability of the destination peer may bedetected via a protocol. For example, a Peer-to-Peer Session InitiationProtocol-Peer (P2P SIP-Peer) protocol may be used to detect looping ofthe diagnosis request message.

A method for handling peer faults is provided in an embodiment of thepresent invention. As shown in FIG. 5, the method includes:

Step 501: Receive a diagnosis response message.

Step 502: Determine a faulty peer according to the diagnosis responsemessage.

If it is determined that the peer is faulty, the diagnosis responsemessage carries information about the faulty peer. Therefore, the faultypeer can be determined according to the information about the faultypeer in the diagnosis response message.

Step 503: Construct a packet to be sent, add the information about thefaulty peer to the packet, and instruct intermediate peers to bypass thefaulty peer in the process of forwarding the packet. In order for thepacket to arrive at the destination peer, the information about thefaulty peer may be inserted into the preset field of the packet. Thepreset field may be a definite Exclude Routing Object (XRO) field.Therefore, before the downstream peer forwards the packet, the currentpeer may judge whether the downstream peer is the faulty peer, namely,the peer specified by the XRO. If the downstream peer is the faultypeer, the current peer selects another downstream peer for forwardingthe packet. Alternatively, according to the default rule, the currentpeer lets the downstream peer forward the packet first, and then judgeswhether the downstream peer is the faulty peer when determining that theforwarding fails; and, if the downstream peer is the faulty peer, thecurrent peer selects another downstream peer for forwarding the packet.Other modes may also be applied if they are appropriate. The embodimentsof the present invention do not limit the mode applied.

Step 504: Send the packet.

In this embodiment, after the diagnosis response message is received, ifthe diagnosis response message carries information about the faultypeer, the information about the faulty peer is inserted into the presetfield of the packet at the time of constructing the packet. Therefore,the downstream peer can bypass the faulty peer at the time of forwardingthe packet; the packet can arrive at the destination peer finally; andthe success ratio of forwarding the packet is increased. The foregoingoperations may be partially or wholly triggered by the correspondinginformation inserted into the corresponding field of the diagnosisrequest message when the source peer constructs the diagnosis requestmessage, where the diagnosis request message may be an existing message,or a newly constructed message. Currently, the Internet Engineering TaskForce (IETF) is developing and standardizing the P2P SIP-Peer protocol.This protocol is designed to create and maintain the P2P SIP Overlaytopology, and intended to provide P2P overlay services such asdistributed storage and distributed forwarding. This protocol providesP2P overlay services for all the applications that are based on the P2Poverlay in the P2P SIP architecture. An embodiment of this protocol isthat one message corresponds to a request and a response. A message iscomposed of a message header and multiple objects. Each object iscomposed of one object header and multiple sub-objects. All objects andsub-objects are in the Type-Length-Value (TLV) format.

In an embodiment of the present invention, the P2P SIP Peer protocol isextended to provide the diagnosis message for fault detection (namely,an Echo message). This message carries an Echo object to indicate theprocessing rule information specified by the diagnosis source. Table 1shows an Echo object header format in this embodiment:

TABLE 1 Echo object header information in P2P SIP Peer protocol ObjectType M U P Reserved Length Forward Mode Reply Mode Reply Rule UnderlayTTL

In the foregoing table, the Object Type field uses an extendeddefinition to indicate that the object type is an Echo object; thisfield occupies 8 bits.

If the M flag value is 1, this object must be identified and processedby all the peers that support the P2P SIP Peer protocol on the P2Pnetwork; for the Echo object, this value is 1; this flag occupies 1 bit.

If the U flag value is 1, the diagnosis source requires that theresponse message should carry its upstream peer information; if thevalue is 0, the response message does not need to carry its upstreampeer information; this flag occupies 1 bit.

If the P flag value is 1, the diagnosis source requires that theresponse peer should forward the detection message even if detecting aforwarding error of the upstream peer; if the value is 0, the responsepeer needs to stop forwarding if detecting a forwarding error of theupstream peer; this flag occupies 1 bit.

The Reserved field is a reserved value, and is all Os for the Echoobject; this field occupies 5 bits.

The Length field occupies 16 bits, and indicates the length of the wholeEcho object measured in bytes, and includes an object header and allsub-objects.

The Forward mode field occupies 8 bits, and indicates the forwardingmode of the intermediate peer; if the value is 0, the intermediate peeritself decides the forwarding mode; if the value is 1, the forwardingmode is the recursive mode; if the value is 2, the forwarding mode isthe iterative mode; if the value is 3, the recursive mode is preferredas the forwarding mode; if the value is 4, the iterative mode ispreferred as the forwarding mode.

The Reply mode field occupies 8 bits, and indicates the sending mode ofthe diagnosis response message of the downstream peer; if the value is0, the downstream peer itself decides the sending mode; if the value is1, the response message is transmitted over IP directly; if the value is2, the response message is transmitted over Overlay.

The Reply rule field occupies 8 bits, and indicates the diagnosisresponse rule of the downstream peer; if the value is 0, no response isrequired; if the value is 1, the intermediate peers do not need to makeany response; if the value is 2, every peer on the forwarding path needsto make a response.

The Underlay TTL field occupies 8 bits, and indicates the TTL value usedat the IP layer when the downstream peer forwards the diagnosis requestmessage.

In practice, the Echo object may include the following sub-objects:

(1) a sub-object that represents the time of the diagnosis sourcesending the diagnosis request message; (2) a sub-object that representsthe time of the downstream peer receiving the diagnosis request message;(3) a sub-object that represents the TTL of the diagnosis requestmessage; and (4) a sub-object that represents the validity period of thediagnosis request message.

After constructing the foregoing Echo object, the source peer sends theEcho object to the downstream peer. After receiving the diagnosisrequest message, the downstream peer checks whether the time ofreceiving the diagnosis request message is out of the validity period ofthe diagnosis request message; if the time of receiving is out of thevalidity period, the downstream peer discards the diagnosis requestmessage directly; otherwise, the downstream peer uses the diagnosisrequest message TTL specified by the diagnosis source plus the time ofreceiving the diagnosis request message as a new validity period of thediagnosis request message, and forwards the diagnosis request message tothe downstream peer, thus suppressing the invalid diagnosis requestmessages on the P2P network.

Any peer on the P2P SIP Overlay can use an Echo message to diagnose thefault that possibly exists on the specified path of the P2P SIP Overlay,for example, detect and locate peer failure, peer congestion, and peerforwarding error.

Specifically, the diagnosis source peer constructs a P2P SIP Echorequest message. The destination ID of this message is the specifiedpeer-ID or resource-ID. The source ID is its own peer-ID. In thisrequest message, the Reply Rule of the Echo object is set to 2; theForward mode is set to 1 or 3, and the Reply mode is decided by the peeritself Before the Echo request message arrives at the destination, theintermediate peers forward the message to the downstream peer of the P2Pnetwork, and then send the Echo response message to the source peer.Finally, the destination peer returns an Echo response message.

A method for detecting peer faults by using the Echo message is providedin the fifth embodiment of the present invention. As shown in FIG. 6,the method includes the following steps:

Step 601: The source peer P2P SIP Peer-1 constructs and sends an Echorequest message to diagnose the fault on the forwarding path of the P2Pnetwork, where the Echo request message is destined for the P2P SIPPeer-4.

Step 602: After receiving the Echo request message from the P2P SIPPeer-1, the P2P SIP Peer-2 discovers that the P2P SIP Peer-2 itself isnot the destination peer, and therefore, forwards the Echo requestmessage further on the P2P network.

Step 603: The P2P SIP Peer-2 sends an Echo response message to thediagnosis source P2P SIP Peer-1. The Echo response message indicates thelocal diagnosis result and diagnosis information, and carries theinformation about the downstream peer P2P SIP Peer-3 that forwards themessage, and this information is the peer-ID of the P2P SIP Peer-3.

Step 604: After receiving the Echo request message from the upstream P2PSIP Peer-2, the P2P SIP Peer-3 discovers that the P2P SIP Peer-3 itselfis not the destination peer, and therefore, forwards the Echo requestmessage further on the P2P network.

Step 605: The P2P SIP Peer-3 sends an Echo response message to thediagnosis source P2P SIP Peer-1. The Echo response message indicates thelocal diagnosis result and diagnosis information, and carries theinformation about the downstream peer P2P SIP Peer-4 that forwards themessage.

Step 606: After receiving the Echo request message from the upstream P2PSIP Peer-3, the P2P SIP Peer-4 finds that the P2P SIP Peer-4 itself isthe destination peer, and therefore, stops forwarding the Echo requestmessage but terminates the Echo request message, and sends an Echoresponse message which indicates its local diagnosis result anddiagnosis information to the diagnosis source P2P SIP Peer-1.

In this embodiment, the P2P SIP Peer-2, P2P SIP Peer-3, and P2P SIPPeer-4 perform the corresponding operations as required by the Echorequest message. Through this embodiment, the faults of the peers aredetected on the forwarding path from the P2P SIP Peer-1 to the P2P SIPPeer-4. It is understandable that FIG. 6 gives only an exemplary mode ofimplementing the present invention. In practice, step 603 may occurbefore step 602, and step 605 may occur before step 604.

Corresponding to the method for detecting peer faults, an apparatus fordetecting peer faults is provided in an embodiment of the presentinvention. As shown in FIG. 7, the apparatus includes:

a message receiving unit 701, adapted to receive a diagnosis requestmessage;

a fault detecting unit 702, adapted to check whether the peer is faultyaccording to a preset fault detection rule; and

a sending unit 703, adapted to send a diagnosis response message to asource peer that constructs the diagnosis request message or a peerspecified by the diagnosis request message, where: the diagnosisresponse message carries a detection result, and the detection resultcarries information about the faulty peer if the peer is detected asfaulty.

Therefore, in this embodiment, a diagnosis request message triggers thepeer to detect the fault state of this peer, thus providing a faultdetection mechanism for the P2P network; after detecting a fault, thepeer sends the detection result to the source peer that constructs thediagnosis request message or the peer specified by the diagnosis requestmessage. Therefore, the source peer that constructs the diagnosisrequest message or the peer specified by the diagnosis request messageknows whether the forwarding path is smooth and decides whether to sendthe packet; further, the returned detection result carries informationabout the faulty peer, and therefore, the source peer that constructsthe diagnosis request message or the peer specified by the diagnosisrequest message can locate the faulty peer and bypass it when sendingthe packet, thus improving the reliability and efficiency of datatransmission in the P2P network.

Further, in order for the source peer that constructs the diagnosisrequest message or the peer specified by the diagnosis request messageto know whether congestion or faults occur between the peers, theapparatus for detecting peer faults in this embodiment may furtherinclude:

a time recording unit, adapted to record the time of the messagereceiving unit receiving the diagnosis request message.

In this case, the sending unit is further adapted to send the time ofthe message receiving unit receiving the diagnosis request message tothe source peer that constructs the diagnosis request message or thepeer specified by the diagnosis request message.

Further, in order for the peer to process only valid messages, theapparatus for detecting peer faults in this embodiment may furtherinclude:

a message validity judging unit, adapted to judge whether the diagnosisrequest message is valid.

In this case, the fault detecting unit is adapted to detect whether thecurrent peer is faulty according to the preset fault detection methodafter the fault detecting unit determines that the diagnosis requestmessage is valid.

Generally, after the fault of the peer is detected, if the peer is notthe destination peer, the diagnosis request message needs to beforwarded further. As shown in FIG. 8, the apparatus for detecting peerfaults in the second embodiment of the present invention includes:

a message receiving unit 801, adapted to: receive the diagnosis requestmessage, and record the time of receiving the diagnosis request message;

a fault detecting unit 802, adapted to check whether the peer is faultyaccording to a preset fault detection rule;

a sending unit 803, adapted to send a diagnosis response message to asource peer that constructs the diagnosis request message or a peerspecified by the diagnosis request message, where: the diagnosisresponse message carries a detection result, and the detection resultcarries information about the faulty peer if the peer is detected asfaulty; and

a destination peer judging unit 804, adapted to judge whether thedestination peer carried in the diagnosis request message is the currentpeer.

The sending unit 803 is also adapted to forward the diagnosis requestmessage to the downstream peer closer to the destination peer or to thedestination peer after the destination peer judging unit determines thatthe current peer is not the destination peer.

In this embodiment, if the current peer is not the destination peer, thediagnosis request message is forwarded to the downstream peer or thedestination peer so that the diagnosis request message may approach orreach the destination peer. Finally, all peers on the whole forwardingpath are detected, and the source peer that constructs the diagnosisrequest message or the peer specified by the diagnosis request messageknows the state of the whole forwarding path, which provides a basis forthe path selection in the subsequent packet forwarding. Further, thepeer does not forward the diagnosis request message unconditionally inall circumstances. For example, when the upstream peer forwards thediagnosis request message incorrectly, the forwarding may be stopped. Asshown in FIG. 9, an apparatus for detecting peer faults in the thirdembodiment of the present invention includes:

a message receiving unit 901, adapted to: receive the diagnosis requestmessage, and record the time of receiving the diagnosis request message;

a fault detecting unit 902, adapted to check whether the peer is faultyaccording to a preset fault detection rule;

a sending unit 903, adapted to: send a diagnosis response message to asource peer that constructs the diagnosis request message or a peerspecified by the diagnosis request message, where the diagnosis responsemessage carries a detection result, and the time of receiving thediagnosis request message;

a destination peer judging unit 904, adapted to judge whether thedestination peer carried in the diagnosis request message is the currentpeer;

an upstream peer judging unit 905, adapted to judge whether the upstreampeer forwards the diagnosis request message to the current peerincorrectly before the message forwarding unit forwards the diagnosisrequest message to the downstream peer closer to the destination peer orto the destination peer; and

a sending unit 903, adapted to forward the diagnosis request message tothe downstream peer closer to the destination peer or to the destinationpeer after the destination peer judging unit determines that the currentpeer is not the destination peer and the upstream peer judging unitdetermines that the upstream peer forwards the diagnosis request messagecorrectly.

In this embodiment, a judgment is made about whether the upstream peerforwards the diagnosis request message incorrectly, and the forwardingof the diagnosis request message to the downstream peer is stopped ifthe upstream peer forwards the diagnosis request message incorrectly.Therefore, the convergence of the whole forwarding path is ensuredbecause the error in forwarding the diagnosis request message by theupstream peer indicates that the upstream peer is faulty or that thenetwork path from the upstream peer to the current peer is faulty. Inpractice, even if the upstream peer forwards the diagnosis requestincorrectly, the diagnosis request message may be forwarded to thedownstream peer, especially when the information about the wholeforwarding path is expected. In this case, although the diagnosisrequest message is further forwarded to the downstream peer, theinformation about the error in forwarding the diagnosis request messageby the upstream peer needs to be notified to the source peer thatconstructs the diagnosis request message or the peer specified by thediagnosis request message. Therefore, the source peer that constructsthe diagnosis request message or the peer specified by the diagnosisrequest message knows the fault, and can locate the faulty peer, whichfacilitates the troubleshooting.

Further, the source peer may require further forwarding of the diagnosisrequest message after the upstream peer forwards the messageincorrectly. In this case, the diagnosis request message carries thecorresponding information. The apparatus for detecting peer faults inthis embodiment may further include:

a forwarding judging unit, adapted to judge whether the diagnosisrequest message carries a flag after the upstream peer judging unitdetermines that the upstream peer forwards the diagnosis request messageto the current peer incorrectly, where the flag requires stop offorwarding the diagnosis request message when the upstream peer forwardsthe message incorrectly; and

a message forwarding unit, adapted to forward the diagnosis requestmessage to the downstream peer closer to the destination peer or to thedestination peer after the destination peer judging unit determines thatthe current peer is not the destination peer, and the upstream peerjudging unit determines that the upstream peer forwards the diagnosisrequest message correctly, and the forwarding judging unit determinesthat the diagnosis request message carries no flag which requires stopof forwarding the diagnosis request message when the upstream peerforwards the message incorrectly.

Likewise, the current peer may stop forwarding the message ifdetermining that the destination peer is unreachable. Therefore, anapparatus for detecting peer faults in this embodiment may furtherinclude:

a destination peer reachability judging unit, adapted to judge whetherthe destination peer is reachable before the message forwarding unitforwards the diagnosis request message to the downstream peer closer tothe destination peer or to the destination peer; and

a sending unit, adapted to forward the diagnosis request message to thedownstream peer closer to the destination peer or to the destinationpeer after the destination peer reachability judging unit determinesthat the destination peer is reachable.

The diagnosis request message is not forwarded after it is determinedthat the destination peer is unreachable, thus reducing unnecessaryoverheads of the system.

Further, the peer may judge success or failure of forwarding thediagnosis request message to the downstream peer. If the peer determinesfailure of forwarding, the peer sends information about the forwardingfailure to the source peer that constructs the diagnosis request messageor the peer specified by the diagnosis request message. Therefore, thesource peer that constructs the diagnosis request message or the peerspecified by the diagnosis request message can locate the downstreampeer directly. As shown in FIG. 10, an apparatus for detecting peerfaults in the fourth embodiment of the present invention includes:

a message receiving unit 1001, adapted to: receive the diagnosis requestmessage, and record the time of receiving the diagnosis request message;

a fault detecting unit 1002, adapted to check whether the peer is faultyaccording to a preset fault detection rule;

a sending unit 1003, adapted to send a diagnosis response message, wherethe diagnosis response message includes a detection result and time ofreceiving the diagnosis request message;

a destination peer judging unit 1004, adapted to judge whether thedestination peer carried in the diagnosis request message is the currentpeer;

an upstream peer judging unit 1005, adapted to judge whether theupstream peer forwards the diagnosis request message to the current peerincorrectly after the destination peer judging unit determines that thedestination peer carried in the diagnosis request message is not thecurrent peer;

a sending unit 1003, adapted to forward the diagnosis request message tothe downstream peer closer to the destination peer or to the destinationpeer after the destination peer judging unit determines that the currentpeer is not the destination peer and the upstream peer judging unitdetermines that the upstream peer forwards the diagnosis request messagecorrectly; and

a forwarding success judging unit 1007, adapted to judge whether themessage forwarding unit forwards the diagnosis request message to thedownstream peer closer to the destination peer or to the destinationpeer successfully after the message forwarding unit performs theforwarding.

The sending unit 1003 is also adapted to send the following informationto the source peer that constructs the diagnosis request message requestor the peer specified by the diagnosis request message after theforwarding success judging unit determines that the diagnosis requestmessage is forwarded to the downstream peer or the destination peerunsuccessfully: information about failure of forwarding the diagnosisrequest message to the downstream peer or the destination peer.

In this embodiment, a judgment is made about whether the diagnosisrequest message is forwarded successfully after the diagnosis requestmessage is forwarded. If it is determined that the forwarding fails, thefailure information is sent to the source peer that constructs thediagnosis request message or the peer specified by the diagnosis requestmessage. Therefore, the source peer that constructs the diagnosisrequest message or the peer specified by the diagnosis request messagecan obtain the information about the faulty downstream peer, and locatethe faulty peer.

Further, in order for the diagnosis request message to arrive at thedestination peer ultimately, the apparatus for detecting peer faults inthis embodiment may further include:

a selecting unit, adapted to: judge whether the diagnosis requestmessage sets a requirement for bypassing the downstream peer in theprocess of forwarding the diagnosis request message after the forwardingsuccess judging unit determines that the diagnosis request message isforwarded to the downstream peer unsuccessfully, and select another peerif such a requirement is set; and

a sending unit, adapted to forward the diagnosis request message to theselected downstream peer.

The apparatus for detecting peer faults in this embodiment may be a peerin the P2P network.

As shown in FIG. 11, an apparatus for handling peer faults in anembodiment of the present invention includes:

a receiving unit 1101, adapted to receive a diagnosis response message;

a peer identifying unit 1102, adapted to determine a faulty peeraccording to the diagnosis response message;

a packet constructing unit 1103, adapted to: construct a packet to besent, add information about the faulty peer to the packet, and instructintermediate peers to bypass the faulty peer in the process offorwarding the packet; and

a packet sending unit 1104, adapted to send the packet.

In this embodiment, after the diagnosis response message is received, ifthe diagnosis response message carries information about the faultypeer, the information about the faulty peer is inserted into the presetfield of the packet at the time of constructing the packet. Therefore,the downstream peer can bypass the faulty peer at the time of forwardingthe packet; the packet can arrive at the destination peer finally; andthe success ratio of forwarding the packet is increased. The apparatusfor handling peer faults in this embodiment may serve as a source peerthat initiates path diagnosis in the P2P network. In practice, the peermay serve as a source peer, or an intermediate peer, or a destinationpeer. Therefore, the peer in practice provides the functions of theapparatus for detecting peer faults, and the functions of the apparatusfor handling peer faults. Those skilled in the art are aware that all orpart of the steps of the foregoing embodiments may be implemented byhardware instructed by a program. The program may be stored in acomputer-readable storage medium. When being executed, the programperforms the following steps:

receiving a diagnosis request message;

detecting whether the peer is faulty according to a preset faultdetection method; and

sending a diagnosis response message to a source peer that constructsthe diagnosis request message or a peer specified by the diagnosisrequest message, where: the diagnosis response message carries adetection result, and the detection result carries information about thefaulty peer if the peer is detected as faulty.

The storage medium may be a Read-Only Memory (ROM), a magnetic disk, ora Compact Disk (CD).

Detailed above are a method and apparatus for detecting and handlingpeer faults under the present invention. Although the invention isdescribed through several exemplary embodiments, the invention is notlimited to such embodiments. It is apparent that those skilled in theart can make modifications and variations to the invention withoutdeparting from the spirit and scope of the invention. The invention isintended to cover the modifications and variations provided that theyfall in the scope of protection defined by the following claims or theirequivalents.

1. A method for detecting peer faults in a Peer-to-Peer (P2P) network,comprising: receiving a diagnosis request message; detecting whether apeer is faulty according to a preset fault detection rule; sending adiagnosis response message to a source peer that constructs thediagnosis request message or a peer specified by the diagnosis requestmessage; wherein the diagnosis response message carries a detectionresult, and the detection result carries information about the faultypeer if the peer is detected as faulty.
 2. The method for detecting peerfaults according to claim 1, further comprising: recording time ofreceiving the diagnosis request message; and sending the time ofreceiving the diagnosis request message to the source peer thatconstructs the diagnosis request message or the peer specified by thediagnosis request message after the diagnosis request message isreceived.
 3. The method for detecting peer faults according to claim 1,further comprising: judging whether a destination peer of the diagnosisrequest message is current peer after receiving the diagnosis requestmessage; and forwarding the diagnosis request message to a downstreampeer closer to the destination peer or to the destination peer if thedestination peer of the diagnosis request message is not the currentpeer; otherwise sending information to the source peer that constructsthe diagnosis request message or the peer specified by the diagnosisrequest message to indicate that the current peer is the destinationpeer if the destination peer of the diagnosis request message is thecurrent peer.
 4. The method for detecting peer faults according to claim3, wherein if the diagnosis request message is forwarded to thedownstream peer closer to the destination peer, the method furthercomprises: sending information about the downstream peer closer to thedestination peer to the source peer that constructs the diagnosisrequest message or the peer specified by the diagnosis request message.5. The method for detecting peer faults according to claim 3, wherein ifthe diagnosis request message is forwarded to the destination peer, themethod further comprises: sending information about the destination peerto the source peer that constructs the diagnosis request message or thepeer specified by the diagnosis request message.
 6. The method fordetecting peer faults according to claim 3, wherein before forwardingthe diagnosis request message to the downstream peer closer to thedestination peer or to the destination peer, the method furthercomprises: judging whether the upstream peer forwards the diagnosisrequest message to the current peer incorrectly; and if the upstreampeer forwards the diagnosis request message correctly, forwarding thediagnosis request message to the downstream peer closer to thedestination peer or to the destination peer.
 7. The method for detectingpeer faults according to claim 6, further comprising: judging whetherthe diagnosis request message carries a flag after it is determined thatthe upstream peer forwards the diagnosis request message to the currentpeer incorrectly, wherein the flag requires stop of forwarding thediagnosis request message when the upstream peer forwards the messageincorrectly; and if the diagnosis request message does not carry such aflag, forwarding the diagnosis request message to the downstream peercloser to the destination peer or to the destination peer.
 8. The methodfor detecting peer faults according to claim 3, wherein beforeforwarding the diagnosis request message to the downstream peer closerto the destination peer or to the destination peer, the method furthercomprises: judging whether the destination peer is reachable; and if thedestination peer is reachable, forwarding the diagnosis request messageto the downstream peer closer to the destination peer or to thedestination peer.
 9. The method for detecting peer faults according toclaim 3, wherein after forwarding the diagnosis request message to thedownstream peer closer to the destination peer or to the destinationpeer, the method further comprises: judging whether the diagnosisrequest message is forwarded to the downstream peer or the destinationpeer successfully; and if the diagnosis request message is not forwardedsuccessfully, sending the following information to the source peer thatconstructs the diagnosis request message or the peer specified by thediagnosis request message: information about failure of forwarding thediagnosis request message from the current peer to the downstream peeror the destination peer.
 10. The method for detecting peer faultsaccording to claim 9, further comprising: judging whether the diagnosisrequest message carries a flag after it is determined that the diagnosisrequest message is forwarded to the downstream peer unsuccessfully,wherein the flag requires the diagnosis request message to bypass thedownstream peer in the forwarding process; and if the diagnosis requestmessage carries such a flag, selecting another downstream peer forforwarding the diagnosis request message.
 11. A method for handling peerfaults in a Peer-to-Peer (P2P) network, comprising: receiving adiagnosis response message; determining a faulty peer according to thediagnosis response message; constructing a packet to be sent; addinginformation about the faulty peer to the packet, and instructingintermediate peers to bypass the faulty peer in the process offorwarding the packet; and sending the packet.
 12. The method forhandling peer faults according to claim 11, wherein the step of addingthe information about the faulty peer to the packet comprises: adding adefinite Exclude Routing Object (XRO) field to the packet, and insertingthe information about the faulty peer into the XRO field.
 13. Anapparatus for detecting peer faults in a Peer-to-Peer (P2P) network,comprising: a message receiving unit, adapted to receive a diagnosisrequest message; a fault detecting unit, adapted to check whether a peeris faulty according to a preset fault detection rule; a sending unit,adapted to send a diagnosis response message to a source peer thatconstructs the diagnosis request message or a peer specified by thediagnosis request message, and wherein the diagnosis response messagecarries a detection result, and the detection result carries informationabout the faulty peer if the peer is detected as faulty.
 14. Theapparatus for detecting peer faults according to claim 13, furthercomprising: a time recording unit; wherein the time recording unit isadapted to record time of the message receiving unit receiving thediagnosis request message; and the sending unit is further adapted tosend the time of the message receiving unit receiving the diagnosisrequest message to the source peer that constructs the diagnosis requestmessage or the peer specified by the diagnosis request message if thetime recording unit has recorded the time of the message receiving unitreceiving the diagnosis request message.
 15. The apparatus for detectingpeer faults according to claim 13, further comprising: a destinationpeer judging unit; wherein the destination peer judging unit is adaptedto judge whether a destination peer carried in the diagnosis requestmessage is the current peer; and the sending unit is further adapted toforward the diagnosis request message to a downstream peer closer to thedestination peer or to the destination peer after the destination peerjudging unit determines that the current peer is not the destinationpeer.
 16. The apparatus for detecting peer faults according to claim 15,further comprising: an upstream peer judging unit; wherein the upstreampeer judging unit is adapted to judge whether an upstream peer forwardsthe diagnosis request message to the current peer incorrectly before thesending unit forwards the diagnosis request message to the downstreampeer closer to the destination peer or to the destination peer; and thesending unit is adapted to forward the diagnosis request message to thedownstream peer closer to the destination peer or to the destinationpeer after the upstream peer judging unit determines that the upstreampeer forwards the diagnosis request message correctly.
 17. The apparatusfor detecting peer faults according to claim 16, further comprising: aforwarding judging unit; wherein the forwarding judging unit is adaptedto judge whether the diagnosis request message carries a flag after theupstream peer judging unit determines that the upstream peer forwardsthe diagnosis request message to the current peer incorrectly, whereinthe flag requires stop of forwarding the diagnosis request message whenthe upstream peer forwards the message incorrectly; and the sending unitis adapted to forward the diagnosis request message to the downstreampeer closer to the destination peer or to the destination peer after theforwarding judging unit determines that the diagnosis request messagedoes not require stop of forwarding the diagnosis request message if theupstream peer forwards the message incorrectly.
 18. The apparatus fordetecting peer faults according to claim 15, further comprising aforwarding success judging unit, wherein: the forwarding success judgingunit is adapted to judge whether the message forwarding unit forwardsthe diagnosis request message to the downstream peer closer to thedestination peer or to the destination peer successfully after themessage forwarding unit forwards the diagnosis request message to thedownstream peer closer to the destination peer or to the destinationpeer; and the sending unit is further adapted to send the followinginformation to the source peer that constructs the diagnosis requestmessage request or the peer specified by the diagnosis request messageafter the forwarding success judging unit determines that the diagnosisrequest message is forwarded to the downstream peer or the destinationpeer unsuccessfully: information about failure of forwarding thediagnosis request message to the downstream peer or the destinationpeer.
 19. The apparatus for detecting peer faults according to claim 18,further comprising a selecting unit, wherein: the selecting unit isadapted to: judge whether the diagnosis request message carries a flagafter the forwarding success judging unit determines that the diagnosisrequest message is forwarded to the downstream peer unsuccessfully,wherein the flag requires the diagnosis request message to bypass thedownstream peer in the process of forwarding the diagnosis requestmessage; and select another peer if the diagnosis request messagecarries such a flag; and the sending unit is further adapted to forwardthe diagnosis request message to the selected downstream peer.
 20. Anapparatus for handling peer faults in a Peer-to-Peer (P2P) network,comprising: a receiving unit, adapted to receive a diagnosis responsemessage; a peer identifying unit, adapted to determine a faulty peeraccording to the diagnosis response message; a packet constructing unit,adapted to: construct a packet to be sent, add information about thefaulty peer to the packet, and instruct intermediate peers to bypass thefaulty peer in the process of forwarding the packet; and a packetsending unit, adapted to send the packet.